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Correction to BBN Report No. 1822 


In the process of generating RFC #271 we have discovered a 
set of errors in BBN Report No. 1822 (NIC 7958). The attached 
page is a corrected version of page 25; in addition the first two 
lines should be deleted from page 26. The paragraph at the top 
of page 25 is changed to show that the Host is not marked dead 
under the stated conditions, and to show that the timeout period 
is 30 (rather than 40) seconds. In the footnote, the two changes 
are underlined; these changes also show the timeout period as 30 
seconds. A more formal update to Report 1822 will be distributed 


eventually. 


Please note that these changes reflect errors in previous ver- 
sions of Report 1822, not changes to the IMP system. The timeout 
period has always been 30 seconds and the Host was never marked 


dead under these conditions. 
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If the hardware interface from the IMP to the Host should 
fail in such a way as to cause any part of a message to remain 
on the output queue to the Host for a period of about 40 seconds, 
the Host is assumed to be broken. In this special case, the IMP 
will reset its interface and reclaim all the buffers on the out- 
put queue to the Host.* The IMP ready line will be dropped for 
approximately 1/4 second to notify the Host that the IMP was 
reset, that messages may have been discarded and that the message 
currently in transmission is to be discarded by the Host. The 
next incoming message from the Host will be discarded by the IMP 
and should therefore be a WOP. 


*For example, the handshake procedure used by the hardware can 
theoretically fall out of sequence and halt; or some component 
in the interface may simply break. The same effect can also be 
produced by a Host that violates the specification to be respon- 
sive and allows any part of a reassembled message to remain in 
the IMP for a period of 30 seconds. 


Whenever a message has remained in reassembly for 15 seconds 
without being reassembled, the destination IMP insures that the 
entire message is discarded and returns an Incomplete Transmis- 
ston message (see Section 3.4) to the source Host. This event 
is unrelated to the 30-second timeout of messages on the output 
queue to the Host and, in particular, the IMP discards no other 
message and does not cause its ready line to drop. 
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The IMP ready line will also be turned off while the IMP 
attempts to reload a copy of the IMP program from the net and 
will remain off for approximately 1/4 second after the program 
is restarted. It takes approximately three seconds to reload 
the program over a 50-kilobit line. A successful reload is 
generally achieved within two or three attempts, or on the first 
attempt when the line happens to be error free. 


An IMP Going Down control message will be sent to the Host 
when its IMP is about to be taken down for maintenance; in this 
case, the ready line will go off shortly thereafter (approximately 


20 seconds later). 
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APPENDIX A 
IMP AND HOST SITE IDENTIFICATION 
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Bits 9-16 of the leader of most Host-to-IMP or IMP-to-Host mes- 
sages define a network address related to the message (these 
bits are not meaningful for message types 1, 2, and 4). Ina 
Host-to-IMP message the network address identifies a particular 
Host to which the message should be delivered. In an IMP-to- 
Host message the network address identifies the Host from which 
the message originated. 


A network address consists of six bits (bits 11-16 of the leader) 
which specify an IMP number, preceded by two bits (bits 9-10 of 
the leader) which specify the Host number of a particular Host 
connected to that IMP. The table below gives the decimal values 
of IMP number, Host number, and network address for each Host 
currently connected to the ARPA Network or scheduled for con- 
nection in the near future. Scheduled installation dates are 
also shown for Hosts not currently connected; these dates, how- 


ever, are subject to change without notice. 


IMP SITE HOST NETWORK SCHEDULED 
NUMBER NAME NUMBER HOST ADDRESS INSTALLATION 
1 UCLA 0  SIGMA-7 1 
1 IBM 360/91 65 
2 SRI O  PDP-10 (NIC) 2 
1 PDP-10 (AI) 66 
UCSB 0O IBM 360/75 3 
UTAH O PDP-10 | 4 
5 BBN O DDP-516 5 ETE p 
1  PDP-10 (A) 69 | 
2 PDP-10 (B) 133 


Note 1: Prior to September 1, 1971 the BBN PDP-10 (A) will be 
Host number 0 (network address 5) and the BBN DDP-516 will be 
Host number 1 (network address 69). The address change is to be 
made during the day on 9/1/71. 
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NETWORK 
HOST 


Honeywell 645 6 


PDP-10 70 
360/65 7 
PDP-10 71 
IBM 360/75 8 
PDP-10 9 
PDP-1 73 
PDP-11 137 
IBM 360/67 10 
TX2 74 
PDP-10 11 
PDP-11 12 
PDP-10 13 
PDP-10 14 
B6500 15 
IBM 360/67 16 
TIP 144 
TIP 145 
H 635/645 18 
TIP 146 
PDP-11 19 
TIP 147 
TIP 148 
418 III 21 
418 III 22 
IBM 360/44 23 
TIP 151 
TIP 152 
CDC 7600 25 
TIP 153 
TIP 158 
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